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ABSTRACT 

An Operations Monitor/Control System (OMCS) was developed to support remote 

f™l Sta l i0n e 4 ui P ment - The g round station controls a Tracking Data Relay Satellite 
( 1 DRS) relocated to provide coverage in the tracking system's zone of exclusion. The 
relocated satellite significantly improved data recovery for the Gamma Ray Observatory 
mission. The OMCS implementation, performed in less than 1 1 months, was mission 
critical to TDRS drift operations. Extensive use of Commercial Off The Shelf (COTS) 
hardware and software products contributed to implementation success. The OMCS has 
been operational for over 9 months with no significant problems. This paper will share 
our experiences in OMCS development and integration. 


INTRODUCTION 

An increase in tape recorder error rates onboard the Gamma Ray Observatory (GRO) 
spacecraft necessitated alternative approaches to data gathering for the GRO mission. 
The project resorted to collecting science data using full period, in view, Tracking and 
Data Relay Satellite (TDRS) return link services. The TDRS system could not track the 
GRO spacecraft in the zone of exclusion. In addition, view periods are frequently 
restricted by spacecraft body blockages. Using the two available spacecraft, TDRS West 
and TDRS East, the project could retrieve only 50% of its science data. 

To increase GRO viewing opportunities, NASA decided to implement a Southern 
Hemisphere TDRS ground station and move a TDRS over the Indian Ocean. The GRO 
Remote Terminal Subsystem (GRTS) Operations Monitor/Control System (OMCS) was 
developed in response to the requirement to provide means to remotely control and 
monitor the Southern Hemisphere ground station located at the Canberra Deep Space 
Communications Complex (CDSCC) at Tidbinbilla in the Australian Capital Territory. 

The driving requirements for the OMCS were: 

• Equipment monitor and control - The main function of the OMCS is to monitor the 
remote ground station equipment and provide status updates within 5 seconds. It was 
also required to control all critical functions for the ground station equipment for 
configuration and fault detection/failure. 

• Provide operator workstations at geographically diverse locations - The main TDRS 

system control center is located in White Sands, New Mexico. It was decided that the 
TDRS satellite controllers would operate the station in Australia remotely from the 
United States with CDSCC personnel providing on site operations support for the first 
year. The White Sands locations was designated the Extended TDRS Ground 
Terminal (ETGT) and the CDSCC location was designated the Remote Ground Relay 
Terminal (RGRT). J 
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• Minimize operator workloads - The OMCS should provide a simple graphical user 
interface to reduce the amount of operator keyboard type-ins. It should also provide 
preloaded configurations to allow one button operation to reduce operator workload 
since the operator would also be the TDRS satellite controller with other operational 
responsibilities. 

• State vector to the antenna subsystems - The OMCS was required to provide a 
method of entry, verification, and transmission of the TDRS and GRO state vectors to 
antenna control computers at RGRT since there was no other method of obtaining the 
vectors. 

The factors that would act as constraints were: 

• Multiple interfaces - Most of the equipment purchased for the ground station had 
never been integrated by ATSC before. About 20 new interfaces had to be 
documented, developed, and tested. 

• Real time integration - Due to the intense development schedule, equipment was to 
be shipped directly to Australia and integrated at the site. 

In summary the OMCS had to be implemented in less that 7 months from project start 

using equipment to be dropped shipped to its final destination. Quite a challenge. 


DEVELOPMENT APPROACH 

Meeting the very aggressive schedule required a new approach to developing the system. 
The decision was made to use COTS products to the maximum extent possible. Several 
COTS approaches were investigated, but Allied Signal Technical Services Company 
(ATSC) had implemented a monitor and control system for another customer using an 
industrial control system. A trade study of current industrial control systems was 
currently being performed for another project and the results were used to aid in the 
selection. The advantages of most industrial control systems is a well defined man- 
machine interface (MMI) and configuration simplicity, i.e. it does not require 
programming, but uses a database to support the equipment interfaces. The real 
advantage of an industrial control system was that it allowed rapid development which 
was key to the success of the OMCS implementation. 

The product chosen was the TIS4000 system developed by Tate Integrated Systems 
located in Owings Mills, MD. The TIS4000 is a distributed data acquisition and control 
system. The TIS4000 system is database driven and has been designed with a flexible 
architecture and a modular, distributed construction. This allows it to be configured for a 
wide range of applications. The basic architecture is based on a "client-server" structure 
with Motorola 68000 series microcomputers performing the real-time control and 
processing operations and RISC workstations providing the MMI functions. All of these 
components are connected via high-speed LANs using TCP/IP networking. The 
advanced workstation MMI uses the UNIX operating system and the X-Windows 
environment. The MMI provides a full graphical operating environment for operators, as 
well as a programming and applications development environment for engineers. 

The TIS4000 is database driven, i.e. parameters to be monitored or controlled are entered 
into a database. The database is downloaded into real-time computers, which perform all 
parameter gathering, limit checking, and alarm notification. The operator displays are 
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created on the workstations using a graphics editor and then connected to the real-time 
parameters. This allows parallel development of the database and displays, reducing 
development time. Each equipment interface can be verified as it is completed and 
changes easily made. Many of the commercial systems evaluated were based on this type 
of architecture. 


OMCS HARDWARE 

Figure 1 provides an overview of the system architecture. At the CDSCC, two 
workstations were placed at Deep Space Station 46 (DSS46), where the equipment is 
located and one at Signal Processing Center 40 (SPC40), the main operations area. Two 
workstations were placed at ETGT, one in the TIC and one in the TOC. An additional 
workstation was located in the GSFC Network Control Center (NCC) for state vector 
entry, user services, and administrative functions. Two real-time computers referred to as 
Input Output Controllers (IOCs) were located in DSS46 and interfaced to the ground 
station equipment. The operational entities were connected locally by an Ethernet local 
area network and standard 9.6 kbps lines were used to interconnect the geographically 
diverse locations. Each workstation can see all of the data provided by the IOCs. 

The workstations are standard SUN Sparc IPX workstations with 32MB of memory, an 
internal 425MB disk and 19" color monitor. During implementation an additional 
425MB external hard disk was added. Hewlett Packard LaserJet IV printers were 
provided. Standard Motorola VME computer components including a 68030 CPU with 
16MB of memory and four communications interface cards configured to meet the 
requirement of 16 serial lines on each. S band Telemetry, Tracking and Control (TTC) 
functions were allocated to one of the real-time computers. Ku band user services were 
allocated to the other real-time computers. This arrangement provided some fault 
tolerance. An Ethernet was installed in Australia and standard bridge/routers are used to 
extend the LAN to White Sands, NM and Washington, DC. 

Figure 2 shows the interfaces to the various RGRT equipment. 


OMCS SOFTWARE 

Figure 3 illustrates the OMCS software architecture. The COTS products are 1 .1 , the 
real-time database processor; 1 .2 and 1 .3, TCP communications stacks; 1 .4, the display 
manager; 1 .5, the display editor; 1 .9 and 1.10, device drivers; and 1 .12, dBase IV used for 
building the real-time database and generating reports. The ATSC developed items are 
1 .6, the state vector entry and transfer; 1 .7 and 1 .8, configuration macros; 1 .13 and 1 .15; 
configuration processes; and 1.14; the checkpoint process. 

The TIS4000 vendor developed, under subcontract, the serial driver required to interface 
the ground station equipment. Due to the schedule this appeared to be the most 
expeditious method of completing a critical portion of the work. 

ATSC engineers working with NASA engineers developed the databases and graphics 
based on interface information provided by the vendors. Personnel from White Sands 
provided operations input to the process. Some pieces of equipment were staged at the 
ATSC facility before shipment to Australia. When the OMCS was shipped in June 1993 
confidence was high that successful on site integration would be possible. Two ATSC 
engineers spend three months on site in Australia completing integration. Additional 
testing was carried out remotely using the workstation in the NCC, reducing travel 


419 



420 






Operations 
Monitor and Control 
S PC-40 


Repeater 


r 



LAN | 

Gateway | 


1 Router 1 

1 Z 

7 

z 

71 

i 

p i 

; 

mmm 

L 

1 


r 



L 

TTtti 1 1 

z L 

TTi in) 

V 



Ground Equipment 
Area 
DSS-46 



Repeater 




LAN 


Serial & 
IEEE-488 
Interfaces 
to 

Intelligent 

Equipment 


Serial & 
IEEE-488 
Interfaces 
to 

Intelligent 

Equipment 


PLC 


TL 


NCC 


Ku-band Antenna 
Area 

PLC 


n 


* / 

in 

ii 

u 

hi 


PLC 


S-band Antenna 
Area 



Router 


to 

'ETGT 


Figure 1: OMCS Systems Architecture 












-p* 

N) 



To ETGT 
White 

— — Sands, NM 


Figure 2: OMCS Equipment Interfaces 





































422 


Operators 


t 

Operator Inputs 




Commands 

Process 
Variable 
Status 


DATA 


Configuration 

Data 



Commands 
Process 
Variable 
Status 


OPERATOR ACTIONS 



OPERATOR ACTIONS 
RAW TREND DATA 


I 

V 


1/D3 

Operator 

History 


1/D2 

Binary 
Trend File 


Process 

Variable 

Status 


Commands 


I Time 

fDatabaaa 



COTS 


GRTS 

Develop 

ed 


Operator Ranging 
Selection 

—Ranging Control- 


_Sweep Pilot 
Command 


rm-TN 

Ranging^ 


_ 1 . 8 _ 

K pilot’ 
k Sweep 


|« Pilot Sweep Control— 


, _ 1.15~ ' 

^\\BUILD\X\; 

.^CONFIGURATIONS, 


1 1/DI 


STATE 


Local 
Configuration 


1/D5 


Checkpoint 

File 


HR VS- 


£ 


~T 

State 


• IIRV Inputs- 


1.6 


3 


r State Vector 
Transfer , 
Processor N 

•y v v n ■■■'j 


£7R - 

Checkpoint 

t ^ \ ■% >i 

Processor, 


'4^-State 


Configuration Databases 


, ,,V ‘ tl! 1 \| 

Queries' 3 '' 0 " 

1 \\\\\\\N 


Serial Commands 
— Serial Status 


_Discrete 

Commands 


■ Discrete Status 



Configuration Change Command 


Commands— K§> 
External CIs 
Status Data^o> 
External CIs 

COMMANDS — ►<§> 
External CIs 
STATUS DATA— <§> 
External CIs 


Figure - 3: OMCS Software Context Diagram 





requirements. Currently , software upgrades are performed remotely from the NCC 


OMCS CAPABILITIES 


The OMCS presents operators with a window into the station. The system works bv a 

C 1C r method ’ with operator keyboard entries reduced to the absolute minimum. 
Normal operations can be performed from a single station overview screen, but the 
operator has the ability to move to lower levels of detail on any specific piece of 
equipment if the need arises. Most detailed equipment screens mimic the actual front 
panel of the equipment, so there is no need for operator retraining on the equipment If a 

the^MCS )erate thC eqUipment fr0m the front P ane1 ’ he can °P erate th e equipment from 

The OMCS is not a fully automated system, nor is it schedule driven. It requires an 

10 ! n / tia ff and a PP rove activities. A decision was made early in the development 
program not to attempt full automation until more operational experience was acquired. 

cnnTm?r?fnr e T^r r K t0r \ S r< ;? uired t0 acknowledge alarms and take corrective measures, 
g ^ f or TTC b y sel ecting active and backup strings, start and stop the uplink carrier, 
start and stop ranging, and switch in redundant equipment if necessary. The operator also’ 
must configure user services and perform Multiple Access (MA) system calibrations 
these operator interactions are not burdensome for such a small TDRS ground station . 

Automatic configuration sequences referred to as "macros" were developed to reduce 
operator workload. All normal configurations are performed by the use of "macros", 
ese are predefined routines that set the station up in a predetermined configuration 

™ ac ; ros allows one-button operation. Typically a macro does nothing more 
than duplicate all steps an operator would perform if configuring the system manually. It 
checks the appropriate equipment status and initiates control actions in the correct 
sequence The macro informs the operator if a piece of equipment is not available 
incorrectly configured, or faulted. The operator can then take the appropriate action. 

Since the major configuration functions have been "automated" in the form of macros 
is provides the first steps towards higher levels of automation if desired. Nothing in' the 
current implementation of the OMCS precludes expanding to full automation or even 
adding an expert system helper. 


CONCLUSIONS 


The implementation of the OMCS was a success, but not a trivial undertaking Many 

e n S ^c d t0 ^ C conc L uered - So J me caused b y g round station equipment, some caused 
proble ms ^ software chosen, and some by the implementers understanding of the 


S iS ^A^c repreSentS th f second in which a COTS industrial control package was used, 
i ne UMLb system implementation was much easier and successful because ATSC has 
refined the requirements for a COTS system from the previous project. The next proiect 
will be easier and less costly to implement because of the experience gained on GRTS. 
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